大家好！歡迎來到鐵人賽第十四天。

昨天，我們讓 n8n 透過 SSH 連線到 Ubuntu 測試機，讓系統開始具備執行維運工作的能力。

但在真正讓系統自動處理漏洞之前，我們還缺少一個很重要的步驟：確認這個漏洞到底是什麼，以及我們的主機是否真的受到影響。

假設 Wazuh 傳來這樣的資料：

• CVE ID：CVE-2023-38325
• Package：curl
• Severity：High

看到這筆告警時，我們可能會直覺認為系統存在高風險漏洞，需要立即進行修補。

但實際上，Severity 只是評估漏洞嚴重程度的參考，並不代表所有安裝該套件的主機都一定受到影響。

在真實的資安維運場景中，我們不能只看到警報就直接登入伺服器執行 apt upgrade，而是必須先查閱相關漏洞情報，確認漏洞的影響範圍與修補方式。

因此，今天我想先讓 n8n 學會一件事情：收到漏洞告警後，自動查詢 CVE 情報，為後續的漏洞驗證做好準備。

一、為什麼需要 CVE 情報？

CVE（Common Vulnerabilities and Exposures）是一套用來識別公開揭露資安漏洞的編號系統。

每個 CVE 都有自己的識別編號，例如 CVE-2023-38325，讓不同的資安工具與漏洞資料庫能夠使用一致的方式查詢同一個漏洞。

當 Wazuh 偵測到漏洞時，我們可以利用 CVE 編號進一步取得相關資訊，例如：

• 漏洞描述： 了解漏洞的成因與可能造成的影響。
• CVSS 分數： 了解漏洞的技術嚴重程度。
• 受影響版本： 確認哪些軟體版本可能受到影響。
• 參考資料： 查閱漏洞公告與相關技術文件。

這些資料能幫助我們進一步判斷漏洞的實際影響。

例如，即使某個漏洞被標示為 High，也不代表所有安裝該套件的主機都一定存在相同風險。

我們還需要確認主機實際安裝的版本、作業系統廠商是否已經回補修補程式，以及漏洞是否需要特定條件才會觸發。

因此，Wazuh 負責告訴我們「可能有問題」，而 CVE 情報則提供更多「問題本身的背景資料」。

不過，取得 CVE 情報並不等於完成漏洞驗證，後續仍需要將漏洞條件與主機實際狀態進行比對。

二、選擇 CVE 情報來源：透過 API 自動查詢

既然我們希望系統能夠自動查詢漏洞資訊，就不能每次都依靠人工搜尋。

這時候，API 就能派上用場。

API 可以讓不同系統透過標準化的方式交換資料。在這次實作中，我們希望讓 n8n 根據收到的 CVE ID，自動向漏洞資料庫發送請求，取得對應的漏洞資訊。

這次我們以 CIRCL CVE API 作為示範的查詢來源。

透過 API，我們可以根據 CVE 編號取得相關漏洞資料，作為後續分析的參考。

不過，需要注意的是，CIRCL CVE API 是漏洞情報的查詢來源，不代表所有回傳內容都是官方修補建議。

如果要確認最新的受影響版本與修補方式，仍然需要進一步查閱 CVE.org、NVD、軟體原廠及作業系統發行商的安全公告。

三、在 n8n 加入 HTTP Request 節點

接下來回到 n8n 的工作流畫布。

原本 Day 13 的流程是：

Webhook → IF / Switch → SSH

當 Webhook 收到資料後，系統會根據條件進行判斷，再決定是否執行後續操作。

今天，我們要在流程中加入一個新的步驟：HTTP Request，讓系統能夠自動查詢 CVE 情報。

調整後的流程如下：

Webhook → HTTP Request（查詢 CVE）→ 後續分析

1. 新增 HTTP Request 節點

首先，在 Webhook 節點後方新增一個 HTTP Request 節點。

接著，進行以下設定：

Method： GET

GET 是常見的 HTTP 請求方法，主要用來向伺服器取得資料。

URL： 設定 CVE 情報 API 的查詢網址。

以 CIRCL CVE API 為例，查詢網址的形式如下：

https://cve.circl.lu/api/cve/{CVE_ID}

其中，{CVE_ID} 就是我們要查詢的漏洞編號。

例如：

https://cve.circl.lu/api/cve/CVE-2023-38325

實際使用前，需要先確認 API 端點是否可用，以及回傳資料的格式。

2. 動態帶入 CVE ID

如果每次都手動修改 URL，就失去了自動化的意義。
因此，我們要讓 n8n 自動讀取 Webhook 傳入的 CVE ID。
假設 Webhook 收到以下 JSON 資料：

{
  "body": {
    "cve_id": "CVE-2023-38325",
    "package": "curl",
    "severity": "High"
  }
}

在 HTTP Request 節點的 URL 欄位中，可以使用 n8n Expression：

{{ 'https://cve.circl.lu/api/cve/' + $json.body.cve_id }}

這段程式碼的意思是：

1. 取得 Webhook 傳入的 body.cve_id。
2. 將 CVE ID 與 API 網址組合。
3. 產生完整的查詢網址。
4. 讓 HTTP Request 節點自動發送 GET 請求。

如此一來，每次收到不同的漏洞告警時，系統就能自動帶入對應的 CVE ID，不需要人工修改網址。

n8n修改位置：

3. 測試查詢結果

完成設定後，我們可以使用測試資料執行工作流，確認：

• Webhook 是否成功收到 CVE ID。
• HTTP Request 是否成功發送請求。
• API 是否正常回傳漏洞資料。
• 回傳內容是否包含後續分析需要的欄位。

如果一切正常，n8n 就能成功取得對應的漏洞情報。

這代表我們已經完成從「接收漏洞編號」到「自動取得漏洞資料」的基本流程。

LINE BOT 推播畫面：

四、RAG 是什麼？讓 AI 根據資料進行分析

做到這裡，我們就可以開始理解近期非常熱門的 RAG 概念。
RAG 全名是 Retrieval-Augmented Generation，中文稱為「檢索增強生成」。
簡單來說，就是不要讓 AI 只依靠原本學習到的知識回答問題，而是先從外部資料來源取得相關資訊，再將這些資料交給 AI 分析。

在我們的資安流程中，RAG 可以分成三個主要階段。

1. Retrieval：檢索

從外部資料來源取得與問題相關的資訊。
在這次實作中，就是透過 HTTP Request 節點查詢 CVE 情報，取得漏洞描述與相關資料。

2. Augmentation：增強

將檢索到的資料整理後，與原本的問題一起提供給 AI。
例如，除了提供 CVE 編號，也可以將漏洞描述、受影響版本與相關公告一併傳遞給 AI。

3. Generation：生成

AI 根據提供的問題與參考資料產生分析結果。
例如，協助整理漏洞重點、說明可能的影響，以及列出需要進一步確認的條件。
將這些概念結合起來，我們的資安流程就可以發展成：

Wazuh 偵測到漏洞
        ↓
Webhook 接收告警
        ↓
HTTP Request 查詢 CVE 情報
        ↓
整理漏洞資料
        ↓
交給 AI 進行分析
        ↓
驗證主機是否受到影響
        ↓
通知管理者或進入後續處置

需要注意的是，AI 的分析結果仍然需要經過驗證，不能只因為 AI 參考了漏洞資料，就認定它的結論一定正確。
今天，我們主要完成的是 RAG 的第一個階段：Retrieval（檢索）。
至於資料整理、AI 分析與主機漏洞驗證，則是後續需要逐步完成的工作。

五、今天的成果總結

今天，我們讓原本只能接收漏洞告警的系統，開始具備自動查詢漏洞情報的能力。

本日完成的內容包括：

• 了解 CVE 情報在資安維運中的用途。
• 認識 API 如何協助系統自動取得漏洞資料。
• 在 n8n 中加入 HTTP Request 節點。
• 使用 Expression 動態帶入 CVE ID。
• 理解 RAG 的基本概念與三個主要階段。

回顧整個系統的演進，我們已經從原本的：

發現漏洞 → 通知 → 執行操作

逐步發展成：

發現漏洞 → 取得漏洞情報 → 準備分析 → 驗證是否需要處置

這讓系統開始具備在執行操作前取得參考資料的能力。
當然，目前我們還沒有完成真正的漏洞驗證，也還沒有讓 AI 自動決定是否需要修補。但這一步非常重要，因為它讓我們開始建立以漏洞情報為基礎的自動化分析流程。

六、明天預告：替系統裝上大腦，讓 AI 開始分析漏洞

今天，我們已經成功建立 CVE 情報檢索的基本流程。

接下來，我開始思考：
如果系統已經能夠自動取得漏洞資料，那麼能不能讓 AI 自己閱讀這些資訊，協助我們分析漏洞的影響與風險？

例如，當 AI 收到漏洞描述、受影響版本與相關公告後，能不能協助我們整理漏洞重點，並指出還有哪些條件需要進一步確認？

下一篇，我們就要正式將 AI 導入 n8n 工作流，讓 AI 根據檢索到的漏洞情報進行初步分析，逐步建立從「取得情報」到「理解漏洞」的自動化流程。
讓系統不只是知道哪裡可能有問題，也開始學習如何根據資料理解問題。
我們明天見！